Notes/Domino Fix List
 |  |
| SPR # YPHG6CY3MN | Fixed in 6.5.5; 7.0.1 release |  |
Product Area: IBM Lotus iNotes Technical Area: Editor Platform: Cross Platform
Lotus Customer Support APAR: LO08498
SPR# YPHG6CY3MN - Fixed a problem where mail body become garbled when UTF-8 for output was enabled.
Technote Number: 1224475
Problem:
This issue was reported to Quality Engineering as SPR# YPHG6CY3MN and has been
addressed in Domino 6.5.5 and 7.0.1.
Excerpt from the Lotus Notes and Domino Release 6.5.5 and 7.0.1 MR fix list
(available at http://www.ibm.com/developerworks/lotus):
Editor
SPR# YPHG6CY3MN - Fixed a problem where mail body become garbled when UTF-8 for
output was enabled.
Refer to the Upgrade Central site for details on upgrading Notes/Domino.
Supporting Information:
Since the UTF-8 output setting is enabled on sender's side, the recipient's
HTML mail will have a tag in the contents to indicate the character set such as:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">.
However, EUC-KR is enabled in the recipient's Domino HTTP setting, so HTML
generated by the recipient's Domino server is basically encoded as EUC-KR when
the document is opened with a browser. This encoding character set information
is sent to the client's Web browser via the HTTP response header.
On the other hand, if the received mail is a Multipart/Related type MIME
message, and is opened with a browser, the HTML of the message body is
generated as separate HTML and is displayed using iFrame by the recipient's
Domino HTTP. See the image below:
The problem is that there is no encoded character set information in the HTTP
response header for the separate HTML. For example, character set information
is missing from HTTP response header for UNID/Body/M1?OpenElement, which is the
part of the Korean characters in the body.
The browser gets the character set information from the HTTP response header
and uses it to display HTML content. But, if there is no information in the
header, the browser will "guess" the character set from the HTML content. If
there is a META tag with the character set information in the contents, the
browser will usually "decide" that it is the character set of the contents.
In this case, there is a META tag of UTF-8 so the browser incorrectly guesses
the character set, even though it is encoded by EUC-KR, and results in the
garbled characters seen in the body of the message.
To fix the problem, in SPR YPHG6CY3MN, the developer included the logic to add
the character set information in the HTTP response header when mail with a MIME
type of Multipart/Related is opened with a browser. More >
Last Modified on 12/11/2013
Go back
|